WidgetServer

Anwendungsentwicklung der nächsten Generation

Während eines früheren Projekts hatte ich bereits Kontakt mit dem WidgetServer. Er umfasst hauptsächlich ein OpenSource Framework für die Anwendungsentwicklung in Java.

Ich habe den letzten Satz absichtlich so neutral wie möglich formuliert, da der WidgetServer eben KEIN übliches Framework für die Entwicklung von Webanwendungen ist. Im Gegensatz zu Frameworks wie Echo oder JSF beschränkt sich nämlich WidgetServer nicht auf den Kanal "HTML", sondern kann mit seinen GUI-Plattformneutralität auch Swing-GUIs bedienen.

Doch beginnen wir ganz von vorn.

Bei meinem aktuellen Arbeitgeber besteht der Bedarf an der schnellen Entwicklung einer webbasierten Administrationsoberfläche für relativ komplexe geschäftslogische Prozesse. Die Konzepte dafür sind natürlich von der Fachseite schnell geschrieben, aber was meist das Hauptproblem darstellt, ist entweder fehlendes oder "zu kreatives" GUI-Design.

Für beides bietet sich mit dem WidgetServer eine hervorragende Plattform für das Prototyping - durch die Definition der GUI in einem XML-Format lässt sich sehr schnell eine Oberfläche zaubern, die Änderungen an der XML-Datei on-the-fly umsetzt und daher wirklich "Rapid" Prototyping ermöglicht.
WidgetServer selbst ist bereits ein stark gereiftes Framework - mittlerweile liegt die Version 1.6.1 vor und dementsprechend mächtig sind die vorhandenen GUI-Komponenten und ihre Funktionalität.

Schon lange bevor der Begriff "AJAX" geprägt wurde, bot WidgetServer bereits für den HTML-Kanal das partielle Rendering an. Auch dies ist ein Grund für die sehr funktionalen Webanwendungen, die sich mit diesem Framework entwickeln lassen.

Der größte Charme des Frameworks liegt aber meines Erachtens darin, dass die serverseitige Programmierung komplette Java-Entwicklung ist und rein gar nichts mit HTML oder HTTP zu tun hat.

Ein Beispiel

Ich brauche einen Button, also füge ich ein XML-Fragment in meine Anwendungsdefinition ein:

<button value="Tu was sinnvolles!" />

So ein Button hat natürlich irgendwie wenig Sinn ohne entsprechende Funktionalität dahinter. Also schreibe ich mir eine kleine Listener-Klasse, die ich per XML mit diesem Button assoziiere:

<button value="Tu was Sinnvolles!">
<srvlistener class="de.zanner.wiser.listener.DoButtonListener" />
</button>

Hier die Listener-Klasse:

package de.zanner.wiser.listener;

// add imports

public class DoButtonListener implements IUnGuiEventListener {

public void pcmf_execListener(UnComponent component) {
   // TODO call business logic, modify component tree, ...
}

}

Wie man an diesem Beispiel bereits erkennt, ist das API etwas gewöhnungsbedürftig: es gibt natürlich keine "Un"-Komponente als undiszipliniertes Pendant einer Komponente ;o) .
Jedes API-Element (Klasse, Interface oder Methode) besitzt einen Präfix, der mehr über den Typen des entsprechenden Artefakts aussagt.
Im Fall der "UnComponent" steht das Präfix für "Unified" und bezeichnet damit eine ganze Reihe von Basisklassen, die gemeinsame Funktionalität sowohl für den Markup- (HTML-) als auch für den Swing-Kanal enthalten.
Analog dazu gibt es noch Präfixe wie "Ke" für "Kernel" für noch allgemeinere Basiklassen ohne Bezug zur GUI oder die Präfixe "Mu" und "Ho" für die kanalspezifischen API-Klassen für die Kanäle "Markup" und "HalfObject".

Am Präfix "Ho" für "HalfObject" erkennbar ist die Verwandschaft des Swing-Kanals zu Frameworks wie "ULC" - dem Ultra Light Client von Canoo oder Nexaweb. Über diesen Kanal kann ich aber wenig Auskunft erteilen, da ich mich momentan nur mit dem HTML-Kanal befasse.

Markup

Hier also etwas mehr Infos über den Markup-Kanal, der üblicherweise für browserbasierte Webanwendungen verwendet wird.

Einfluss auf das Aussehen der einzelnen Komponenten kann über Template-Dateien genommen werden, die von Renderer-Klassen dazu verwendet werden, die Komponente zusammenzubauen.
Hier wird auch ersichtlich, warum der Kanal "Markup" und nicht etwa "HTML" heißt - es kann in dem Template natürlich beliebiger Markup-Code enthalten sein. Mit dem passenden Renderer dazu kann dann beispielsweise anstelle von HTML WML gerendert werden.
Lieferbestandteil ist ein kompletter HTML-Kanal für den InternetExplorer und Gecko-basierte Browser (Mozilla).

Entwicklung neuer Komponenten

Neue Komponenten können also recht einfach über ein eigenes Template und eine neue zugehörige Rendererklasse erstellt werden.
Die Assoziation von Renderer und Template geschieht in einer XML-Konfigurationsdatei, so dass das Erstellen neuer Komponenten auch über die Abwandlung bestehender Templates und Verwendung des bestehenden Renderers möglich ist, z. B., um einen Tabellenkopf anders zu gestalten als in der Standardtabelle vom WidgetServer.

Fazit

Der Fokus des WidgetServer liegt eindeutig auf Produktivität - ein ganz klarer Pluspunkt. Standards wie AJAX über XMLHTTPRequest findet man hier allerdings wenig.
Einziger Berührungspunkt mit der Servlet API ist z. B. das Servlet zur Kommunikation zwischen JavaScript-Bibliothek und WidgetServer.

Der Einstieg in die Entwicklung mit dem WidgetServer ist nicht ganz intuitiv.
Es gibt z. B. (noch) kein XML-Schema für die XML-Datei, welche die Anwendung definiert.
Etwas Abhilfe schafft hier der mit gelieferte GUI-Builder, der auch Doku zu den einzelnen Attributen liefert, aber leider dem aktuellen Release immer um 1 bis 2 Versionen hinterher läuft.

Der Aufbau der API ist zwar in sich logisch - aber erst, wenn man die Logik einmal verstanden hat ;o)...
Das aktuelle Geschäftsmodell der Firma C1 SetCon, für die der Entwickler des WidgetServer (Dirk von der Weiden) mittlerweile tätig ist, sieht daher ein "Startup Consulting" vor, das den Anwender in die Lage versetzen soll, selbst mit dem WidgetServer zu entwickeln.

Für meine Begriffe sind die üblichen 10 Tage für bereits vorbelastete GUI-Entwickler etwas zu hoch gegriffen. Wer darüber hinaus noch Erfahrung in der Swing-Programmierung hat, findet sich wirklich schnell zurecht, wenn die größte Einstiegshürde "GUI-Definition in XML" überwunden ist.

Für die Entwicklung von Anwendungen mit Kundenkontakt ist eine WidgetServer-Anwendung zu wenig an die Bedürnisse modernen Screen-Designs anpassbar. Für jedes neue Projekt ein neues Template-Kit zu schreiben ist mit Sicherheit zu aufwändig.
Für interne Anwendungen, bei denen es keine Beschränkungen hinsichtlich JavaScript gibt und die dann meist auch den Anspruch an hohe Interaktivität und desktopanwendungsähnliches Look-and-Feel haben, ist diese Lösung einer klassischen Webentwicklung mit Struts oder JSF haushoch überlegen.

Leider hat der WidgetServer etwas zu wenig sichtbare Community, was sicherlich einige potenzielle Anwender abschreckt.
Das liegt wahrscheinlich daran, dass der Dirk von der Weiden in Consulting-Projekte eingebunden ist und daher wenig Zeit bleibt, eine Community zu pflegen. Das ist auch der Grund, warum die Sourceforge- und java.net-Seiten etwas vernachlässigt werden.
C1 SetCon - speziell der Hauptentwickler Dirk von der Weiden - tut aber sehr viel dafür, die Wünsche und Bedürfnisse der Anwender umzusetzen und zu befriedigen.
Ein weiterer WidgetServer-Entwickler - Thomas Boshell - hat ein eigenes (englischsprachiges) Blog mit einer Kategorie zum WidgetServer.

Ich hoffe, dass durch mein Blog der WidgetServer etwas bekannter wird. Zumindest in Deutschland sollte er leicht Verbreitung finden, da die dahinter stehende Firma eine deutsche ist.
An alle, die angesichts eines deutschen Software-Produkts die Nase rümpfen: ein gutes Framework zur Webanwendungsentwicklung muss nicht aus den USA oder dem Ostblock kommen ;o) !

"Beyond Java" (Bruce A. Tate)

Ohne einen Anspruch auf ein fundiertes Literatur-Review hier mal mein erster Versuch einer Buchbesprechung. Ein Kollege, der im übrigen ziemlich fit in Java und Software-Architektur ist, hat mir obiges Buch ans Herz gelegt.

Im großen und ganzen enthält es Meinungen verschiedener bekannter Java-Entwickler über den aktuellen Stand und die Zukunft von Java als Programmiersprache. Kurze Essenz: Java sei als Programmiersprache für die normale Webanwendungsentwicklung zu komplex geworden. Statt dessen sollte für den Standard Anwendungsentwicklungsfall "Webanwendung auf Datenbank" über Alternativen nachgedacht werden. Es geht also um die Betrachtung potenzieller Nachfolgekandidaten für Java - aber nur in diesem begrenzten Szenario.
Dass dabei Ruby - insbesondere in Verbindung mit dem Webanwendungs-Framework Rails - nicht fehlen darf und sogar die Motivation zu diesem Buch darstellt, ist angesichts des aktuellen Hypes um diese in Japan enstandene Programmiersprache nicht verwunderlich.

Ich war ja etwas skeptisch. Bei neuen Programmiersprachen sowieso. Wahrscheinlich nicht gerade die besten Voraussetzungen für meine persönliche Weiterentwicklung. Aber wenn mich etwas Neues überzeugt (bzw. jemand anderes von etwas Neuem überzeugt ;o) ), kann ich es auch sehr schnell umsetzen und weiter geben. Auch wenn ich schon einiges über Ruby gelesen habe, hat mich daher erst der Hinweis von meinem Kollegen dazu animiert, mich überhaupt erst mit Ruby zu befassen.

Der Autor ist vorher bereits durch das Buch "Better, Faster, Lighter Java" in Erscheinung getreten und daher auch kein unbeschriebenes Blatt, was die Beurteilung von Java-Features angeht. Seine Meinung von Java ist stark geprägt von einer sehr großen Erfahrung im Consulting im Bereich Java-Anwendungsentwicklung. Ihm kann man in Sachen Java also keine mangelnde Fachkompetenz unterstellen.
Außerdem dringt aus jeder Zeile eine große Leidenschaft für Java hervor - er versucht also nicht, Java schlecht zu machen, sondern zeigt ziemlich objektiv die Schwächen von Java im Bereich Anwendungsentwicklung auf.

Als größte Schwäche kommt hier m. E. zum Tragen, dass der Fokus von Java und dem zugehörigen JCP sich immer mehr in Richtung serverseitige Programmierung verschoben hat. Die Produktivität im Bereich Anwendungsentwicklung hingegen ist durch die Komplexität der APIs und der Fülle an benötigten Frameworks aber immer weiter gesunken.

Produktivität bei der Anwendungsentwicklung sei aber heute das Maß der Dinge im schnelllebigen Internet-Markt und Java hat hier seiner Meinung nach den Anschluss verloren.

Aus den aufgestellten Schwächen der aktuellen Java 5 Version heraus abgeleitet stellt er eine Liste von Kriterien auf, die ein potenzieller Java-Nachfolger in diesem Bereich haben sollte. Dabei werden Konzepte wie Static/Dynamic Typing oder Strong/Weak Typing, Closures, Continuations usw. beleuchtet.
Int3eressanteweise geht er gerade mit den Features von Java, die in die neue version Einzug gehalten haben, um Java für die Zukunft zu rüsten (Generics, Auto-boxing) ziemlich hart ins Gericht - was man aber letzten Endes durch seine immer sehr guten Begründungen relativ schnell nachvollziehen kann.

Das ganze Buch ist gespickt mit Interviews mit aktuellen oder ehemaligen Java-Experten, über die man auch sehr viele Hintergrundinformationen zu Java und dem aktuellen Entwicklungsprozess sowohl in der Java- als auch speziell der Webanwendungsentwicklungs-Community erhält.

Ich bin ja seit meinem Kontakt mit der JSF-Spezifikation sowieso ein wenig ein gebranntes Kind, was den Java Community Process angeht. Aus meiner Sicht entstehen hier überwiegend von der Software-Industrie getriebene Kompromisse auf Kosten der Bedürfnisse des Markts geschlossen.

Das Buch ist also auch zur Erweiterung des eigenen Horizonts eine interessante Lektüre - mir hat sie an einigen Stellen die Augen geöffnet.
Außerdem ist das Buch nicht sehr dick und liest sich daher an einigen Tagen durch. Bei mir stauben die sonst üblichen 400+ Seiten Wälzer immer ungelesen ein - dieses Buch habe ich von der ersten bis zur letzten Seite verschlungen!